TCP Authentication Option (TCP-AO), described in RFC 5925, June 2010, replaces the conventional TCP MD5 authentication mechanism and is used to authenticate TCP segments for long-lived Border Gateway Protocol (BGP) sessions, Label Distribution Protocol (LDP) sessions, BGP route reflectors, or any other client-server TCP applications. Unlike TCP-MD5, TCP-AO supports the use of stronger hash functions, provides replay protection for long-lived connections and across repeated instances of a single connection, coordinates key changes between endpoints, and provides a more explicit recommendation for external key management to use, which could be either manual or auto key management.
TCP-AO allows re-keying during a TCP connection (assuming that an out of band protocol or manual mechanism provides the new keys). The option includes a key ID that allows the efficient concurrent use of multiple keys. A key coordination mechanism using a “receive next key ID” manages the key change within a connection.
TCP-AO supports key changes with zero segment loss. TCP-MD5 can lose segments in transit during the changeover or require trying multiple keys on each received segment during key use overlap because it lacks an explicit key ID. Although TCP recovers lost segments through retransmission, loss can have a substantial impact on performance.
TCP-AO provides automatic replay protection for long-lived connections using sequence number extensions.
TCP-AO includes TCP's socket pair (source address, destination address, source port, destination port) as a security parameter index (together with the Key ID), rather than using a separate field as an index (e.g., IPsec's Security Parameter Index (SPI)).
TCP-AO ensures per-connection traffic keys as unique as the TCP connection itself, using TCP's Initial Sequence Numbers (ISNs) for differentiation.
TCP-AO defines a Master Key Tuple (MKT), which is used to derive unique traffic keys and includes the keying material used to generate those traffic keys (such as the master key), as well as indicates the associated parameters under which traffic keys are used. Such parameters include whether TCP options are authenticated and indicators of the algorithms used for traffic key derivation and Message Authentication Code (MAC) calculation. Each MKT contains the following as described in RFC 5925:                TCP connection identifier. For example, a TCP socket pair (local IP address, remote IP address, TCP local port, and TCP remote port). Values can be partially specified using ranges (e.g., 2-30), masks (e.g., 0xF0), wildcards (e.g., *) or other suitable indication.        TCP option flag. This flag indicates whether TCP options other than TCP-AO are included in the MAC calculation. When options are included, the content of all options, in the order present, is included in the MAC with TCP-AO's MAC field zeroed out. When the options are not included, all options other than TCP-AO are excluded from all MAC calculations (skipped over).        IDs (KeyID, RNextKeyID) SendID, ReceiveID. The values used in the KeyID or RNextKeyID of TCP-AO, which are used to differentiate MKTs in concurrent use (KeyID), as well as to indicate when MKTs are ready for use in the opposite direction (RNextKeyID). Each MKT has two IDs, a SendID and ReceiveID. The SendID is inserted as the KeyID of the TCP-AO option of outgoing segments, and the ReceiveID is matched against the TCP-AO KeyID of incoming segments.        Master key. A byte sequence used for generating traffic keys, which may be derived from a separate shared key by an external protocol over a separate channel.        Key Derivation Function (KDF). Indicates the key derivation function and its parameters that are used to generate traffic keys from master keys.        Message Authentication Code (MAC) Algorithm. Indicates the MAC algorithm and its parameters as used for this connection.        
In TCP-AO, a traffic key is a key derived from the MKT, the local and remote IP address pairs and TCP port numbers, and the TCP Initial Sequence Numbers (ISNs) in each direction. A single MKT can be used to derive a Send_SYN_traffic_key (used to authenticate outgoing SYNs), a Receive_SYN_traffic_key (used to authenticate incoming SYNs), a Send_other_traffic_key (used to authenticate all other outgoing TCP segments), and/or a Receive_other_traffic_key (used to authenticate all other incoming TCP segments).
The Key Derivation Function (KDF) defined in RFC 5925 has the following interface:
traffic_key=KDF_alg(master_key, context, output_length),
where:                the KDF_alg is the specific KDF that is used to construct the traffic key as indicated in the MKT;        the master_key is the master key stored into the associated MKT;        the context is used as input in constructing the traffic key (e.g., S-IP, S-Port, S-ISN, D-IP, D-Port, and D-ISN);        the output length is the desired output length of the KDF; and        the traffic_key is the desired output of the KDF, of length equal to the output length, which is to be used as input to the MAC algorithm to protect the TCP segments        
The following table indicates how each of the traffic keys are computed, where the TCP-AO algorithms refer to source (S) and destination (D) values of the IP address, TCP port, and ISN, and each segment (incoming or outgoing) has a value that refers to the local side of the connection (l) and a remote side (r):
S-IPS-PortS-ISND-IPD-PortD-ISNSend_SYN_traffic_keyl-IPl-portl-ISNr-IPr-port0Receive_SYN_traffic_keyr-IPr-portr-ISNl-IPl-port0Send_other_traffic_keyl-IPl-portl-ISNr-IPr-portr-ISNReceive_other_traffic_keyr-IPr-portr-ISNl-IPl-portl-ISN
Thus, four different keys are derived based on parameters as provisioned in the MKT and using the out of band provisioned master key.
TCP-AO is commonly deployed with manually provisioned keys at both peers who are interested in integrity protection of the session. As described in IETF draft “The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports”, draft-ietf-karp-threats-reqs-03, Jun. 18, 2011, there is an issue with master key compromise because of a terminated/turned employee or out-of-band master key access. In the TCP-AO manual method described in RFC 5925, although unique traffic keys are generated with the master key and other session specific parameters through the Key Derivation Function (KDF), the unique traffic keys cannot protect the session when master key itself is compromised. This is not a problem that is isolated to TCP-AO as it is also a problem for any manual key management protocol.